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I. Phases de creation d’un proiet informatiaue 

A. Cycle de vie d’un proiet informatiaue 


L'aboutissement d'un projet informatique est un processus complexe dont la reussite 
depend de 3 parametres : le temps, I'equipe de travail et le budget. 

Ce processus contient les risques suivants : 

Non-respect du delai de livraison 
-> Depassement du coOt 

Non-respect des fonctionnalites demandees 



Comment le client Comment le chef de Comment I'ingenieur Comment le Comment le responsable 

a exprime son besoin projet I'a compris I'a con$u programmeur I'a ecrit des ventes I'a decrit 



Comment le projet Ce qui a finalement Comment le client Comment la hotline Ce dont le client avait 
a ete documents ete installe a ete facture repond aux demandes reellement besoin 


Afin d'eviter ces risques, il est necessaire de suivre les etapes suivantes : 

■ Preparation : 

o Etude generale du projet et de sa faisabilite 
o Mise au point du plan d 'organisation et de deroulement du projet 
o Redaction du cahier des charges 


■ Realisation : 

o Analyse des besoins issus du cahier des charges : deqaqer la description 
technique et fonctionnelle de ce que doit taire le logiciel 
o Conception des modeles ou modelisation : representation graphique des 
besoins sous formes de schemas appeles « modeles » 
o Codages ou programmation : traduire les modeles en algorithmes, puis en 
programmes ecrits en langage de programmation (Java, Visual Basic, 

PHP, C++, ...) 

o Tests : tester le bon fonctionnement de chaque composant du logiciel 
o Integration : rassembles tous les composants du logiciel pour former le 
produit final 
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■ Validation : Verifier si le produit est conforme aux besoins exprimes dans le cahier 
des charges 

■ Documentation & formation : Rediger les documents necessaires a I ’ utilisation du 
logiciel, et former les prochains utilisateurs sur ce dernier si c'est necessaire 

■ Livraison : Installation du livrable chez le client 

La phase de realisation est I'etape concrete de creation du logiciel. 

Le cycle de vie de ce dernier est souvent represente dans cette phase par ce qu'on 
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B. Pourquoi modeliser 

La conception, ou modelisation, consiste a schematiser, ou creer une representation 
virtuelle, des besoins exprimes dans le cahier des charges. 

Cela permet de : 

Minimiser au maximum les erreurs lors de la phase de programmation, car durant 
cette phase, les erreurs sont beaucoup plus coOteuses en temps, done en 
argent. 

Assurer la coherence et eviter la redondance des donnees 
Assurer la conformite du logiciel aux exigences du client 


Exemple : Gestion de commandes 


N°Comm 

dateComm 

N°Client 

nomClient 

prenomClient 

adresse 

11 

23/10/2010 

5 

AFIFI 

Omar 

Lot. ElMenzeh, N°665, ELJadida 

12 

23/10/2010 

5 

AFIFI 

Omar 

Lot. ElMenzeh, N°665, ELJadida 

64 

02/02/201 1 

11 

RAF IQ 

Mohamed 

Av. 2 Mars, Res. Islam, N°15, Kenitra 


Pour 2 commandes, les informations du client N°5 sont saisies 2 fois. 

II serait plus logique d'avoir deux tableaux avec un lien entre les deux : 


N°Comm 

dateComm 

N°Client 

11 

23/10/2010 

5 

12 

23/10/2010 

5 

64 

02/02/201 1 

11 


£ 


Table des commandes 


Lien 


Table des clients 


N°Client 

nomClient 

prenomClient 

adresse 

5 

AFIFI 

Omar 

Lot. ElMenzeh, N°665, ELJadida 

11 

RAF IQ 

Mohamed 

Av. 2 Mars, Res. Islam, N°15, Kenitra 


Les questions qui se posent done sont : 

-> Quel champ doit etre place dans quelle table ? 

-> Quel est le champ qui jouera le role du lien entre les tables ? 


Pour repondre a ce genre de questions, il est necessaire de recourir a une solution 
d'analyse et de conception qui soit methodique et standardisee. Les plus utilisees 
sont MERISE et UML. 
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C. Introduction a UML 

1. Definition 

UML ( Unified Modeling Language ) est un langage, ou notation, de modelisation 
graphique a base de diagrammes, utilise dans la conception & developpement 
orientes objet. 

UML est un langage standardise par I Object Management Group 
( http://www.uml.org) 

La derniere version diffusee par I'OMG est UML 2.4.1 depuis aoOt 201 1 . 

2. Quand utiliser UML 


Cahier des charges 


Redaction des specifications fonctionnelles 
& techniques 


\/ i 



Analyse & conception: diagrammes UML 







Realisation: codages, base de donnees, 
implementation reseau, ... — 

— 

Tests: tests unitaires, tests d'integration, ... 
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3. Apercus sur les diaqrammes d’UML 

Les diagrammes UML se repartissent en 2 grands groupes : 
Diagrammes structurels ou statiques 
Diagrammes comportementaux 


Diagrammes structurels ou statiques 


-> Diaqramme de classes (Class diagram) 

-> Diaqramme d'objets (Object diagram) 

Diaqramme de composants (Component diagram) 

Diaqramme de deployment (Deployment diagram) 

-> Diaqramme des paauetaqes (Package diagram) 

Diaqramme de structure composite (Composite structure diagram) 
Diaqramme de profils (Profil Diagram) 


Diagrammes comportementaux 


-> Diaqramme des cas d'utilisation fuse-cases ou Use Case Diagram) 
Diaqramme d’etats-transitions (State Machine Diagram) 

Diaqramme d'activite (Activity Diagram) 

-> Diaqramme de sequence (Sequence Diagram) 

Diaqramme de communication (Communication Diagram) 

Diaqramme global d'interaction (Interaction Overview Diagram) 

Diaqramme de temps (Timing Diagram) 

(Les 4 derniers sont souvent appeles Diagrammes d'interaction ou dynamiques) 


Grace aux outils de modelisation UML, il est egalement possible de generer 
automatiquement des parties de code (par exemple en longoge Java) ou des 
supports de documentation a partir des modeles realises. 
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II. Diaarammes d ’analyse 

A. Modelisation des besoms : Diaaramme des cas d' utilisation 
1 . Definition 


Definition : Besoins fonctionnels / techniques 


Tires du cahier des charges, les besoins ou exigences sont I'expression documentee de 
ce qu'une application informatique devrait faire ou doit etre 

Deux types d 'exigences : 

-> Exigences fonctionnelles 

Decrivent le systeme sur le plan fonctionnel, c.a.d. ce aue le systeme doit faire. 

Elies refletent les besoins exprimes par le client dans le cahier de charges, et elles ne sont 
pas negociables. 

En general, ce genre d'exigences repond a la question : « Pourquoi I'utilisateur aurait-il 
besoin de I'application ?» 

-> Exigences non fonctionnelles (ou techniques) 

Decrivent le systeme sur le plan technique, c.a.d. la maniere dont il execute les 
fonctionnalites aue I'utilisateur lui demande 

Elles refletent generalement les contraintes techniques imposees par I'architecture 
logicielle du futur produit : le choix de la plateforme et du langage de programmation, le 
type de systeme d 'exploitation vise (Unix, Windows, Android, ...), le deployment sur le 
reseau ( machine locale, intranet, internet, ...), etc. 

Ce genre d’exigences peut etre exprime par le client ou par le developpeur 


Exemple : Besoins fonctionnels / techniques 
Etude de cas : Sites internet pour reseaux sociaux 


■ Pouvoir ouvrir plusieurs conversations instantanees a la fois : figure parmi les services 
les plus elementaires et indispensables d'une application de reseau social, ce service 
doit done etre considere comme une exigence fonctionnelle 

■ Pouvoir ouvrir plus de 50 conversations instantanees a la fois : ceci peut etre 

realisable ou non, selon I’architecture technique de I'application (plateforme, 
environnement de developpement, langage de programmation, ...), ce service doit 
done etre considere comme une exigence non fonctionnelle 
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2. Analyse des besoins 


Exemple : Besoins fonctionnels / techniques 
Etude de cas : Guichet automatique bancaire (GAB) 


A partir du texte du cahier de charges de I'application du GAB, on peut deduire les 
exigences suivantes : 

■ Exigences fonctionnelles 

- L'utilisoteur doit pouvoir consulter le solde de son compte 

- L'utilisoteur doit pouvoir extraire un mini-releve de son compte 

- L'utilisoteur doit pouvoir retirer de I'argent de son compte 

■ Exigences non fonctionnelles 

- L’operation d’extraction d’un mini-releve de compte boncoire ne doit pas durer plus 
de 5sec 

- Lors de T operation de retrait d'argent, si Tutilisateur tape un montant superieur au 
montant maximal, un message d’erreur doit lui indiquer le montant a ne pas depasser 


Etude de cas : Gestion commerciale 


[ 

Pour passer une commande le client s’ adresse au receptionniste, celui-ci passe la 
commande (commande normale ou express) si le client existe deja, sinon il doit d’abord 
le creer. 

Le comptable ou le directeur des ventes peuvent enregistrer la facture de chaque 
commande dont le paiement est dOment regie. 

Le livreur doit enregistrer chaque livraison qu ’il effectue. 

Pour les commandes dont la liste de produits n ’existe pas en quantite suffisante, le 
directeur des ventes peut aussi gerer le stock pour eviter toute rupture de produits. 

La gestion du stock contient les fonctionnalites suivantes : 

Gerer un produit, et enregistrer une demande d’ alimentation du stock 
La gestion d’un produit contient les fonctionnalites suivantes : 

Aj'outer, supprimer et mettre a j'our un produit 

Chaque utilisateur du systeme, doit d’abord s’authentifier avant de pouvoir acceder a 
n’importe quelle fonctionnalite. 

] 

Travail a faire : 

Rediger la liste des exigences fonctionnelles 
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3. Moderation des besoins : Diaqramme des Cas d'utilisation 




Le diagramme des cas d'utilisation - use case diagram - est consider'd comme le point 
d’entree de la phase d'analyse, il permet de modeliser toutes les fonctionnalites que doit 
fournir le systeme. 

Le formalise graphique du DCU est principalement base sur les acteurs et les cas 

d’utilisation 


Chaque exigence ou besoin fonctionnel identifie dans la phase de redaction des 
exigences, est represente par un use-case. 



Acteur 



Cas d'utilisation 
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4. Realiser le UCD 
-> Les acteurs 


Definition : Les acteurs 


Les acteurs sont soit (le plus souvent) des utilisateurs humains du systeme, soit 
d'autres systemes informatiques ou hardwares qui vont communiquer avec le 
systeme. 

Exemples : 

Gestionnaire de stock, charge de clientele, administrateur, ... 


Exemple 

Fragment d’un cahier de charges : Gestion commerciale 


[... 

Le directeur des ventes est un prepose aux commandes, mais avec un pouvoir 
supplementaire : en plus de pouvoir passer et suivre une commande, il peut gerer le 
stock. 

Par contre, un simple prepose aux commandes n'a pas le droit d’acceder a la gestion 
du stock 




Prepose aux 
commandes 

Directeur des ventes 


Les relations entre acteurs 

La seule relation possible entre deux acteurs est le lien d'heritage (ou 
generalisation) : 


Definition : L'heritage entre acteurs 


On dit qu'un acteur A est une generalisation d'un acteur B, on dit aussi : I’acteur B est un 
cas particulier de I'acteur A, quand : 

Tous les cas d'utilisation appartenant a I'acteur A, appartiennent aussi a B 
On dit alors que B herite de A 
Notation graphique de l’heritage : 



A B 


Exemple 

Etude de cas : Gestion commerciale 


[... 

Le prepose aux commandes peut passer une commande, et suivre une commande. 

Le directeur des ventes est lui aussi un prepose aux commandes, mais avec un pouvoir 
supplementaire : en plus de pouvoir passer et suivre une commande, il peut gerer le 
stock. 

Par contre, un simple prepose aux commandes n’a pas le droit d’acceder a la gestion 
du stock 
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-> Les cas d’utiiisation 


Definition : Les cas d'utilisation 


o 


Chaque cas d’utiiisation represente une exigence fonctionnelle. 

Exemples : 

Retlrer argent, Passer une commonde, Supprimer un produit, ... 


Exemple 

Cas d’utiiisation : Retirer argent 
Etude de cas : GAB 



Un cas d'utilisation doit obligatoirement avoir les elements suivants : 

■ Un nom 

Le nom d'un cas d'utilisation commence generalement par un verbe a I'infinitif 

A IMPORTANT 

■ Deux ou plusieurs cas d'utilisation ne peuvent avoir le meme nom. 

■ Un cas d'utilisation ne peut avoir plusieurs noms. 

■ Un ou plusieurs acteurs declencheurs 

Un use-case doit avoir au moins un seul acteur declencheur. 


Definition : Acteur declencheur 


Un acteur declencheur d'un use-case A est un acteur qui utilise le systeme pour acceder 
a la fonctionnalite representee par le cas A. 


Exemple 

Etude de cas : Gestion de centre de formation 


[... 

Le dlrecteur pedagogique peut ajouter ou supprimer des modules tout au long de 
I’annee scolaire 

■] 


On peut done dire que I'acteur directeur pedagogique est I'acteur declencheur des cas 
d'utilisation ajouter un module et supprimer un module 


© REMARQUES 

■ Un acteur peut posseder plusieurs cas d'utilisation. 

■ Un use-case peut avoir plusieurs acteurs declencheurs. 
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• Des scenarios 

Un cas d ’ utilisation doit obligatoirement avoir un scenario principal (unique), et peut 
avoir un ou plusieurs scenarios secondaires. 


Definition : Scenario / Scenario principal / Scenario secondaire 


■ Scenario : decrit (sous forme de texte) les echanges d'evenements entre I'acteur et le 
systeme. 

■ Scenario principal : represente le deroulement de la realisation avec succes du use- 
case. II doit se terminer par la fin attendue de la part de I'acteur declencheur. 

■ Scenario principal : permet de preciser la conduite a tenir par le systeme en cas 
d'anomalies ou d'erreurs. 

■ Scenario alternatif : scenario sans erreur mais qui decrit une fin alternative a celle du 

scenario principal. 


Exemple 

Etude de cas : GAB 

Cas d’utilisation : « Retirer argent » 


Scenario principal : Argent retire 

Scenario d’erreur N°1 : Carte invalide, fin du scenario : carte ejectee 

Scenario d’erreur N°2 : Mot de passe invalide, fin du scenario : carte aspiree 

Scenario d’erreur N°3 : Caisse epuisee, fin du scenario : carte ejectee 

Scenario d’erreur N°4 : Solde insuffisant, fin du scenario : carte ejectee 


-> La relation d’association entre acteur et cas d’utilisation 

Chaque acteur doit etre lie par un lien d’association avec tous les use-cases qu'il 
declenche, ce lien est represente par un trait continu 


Exemple 

Etude de cas : Gestion commerciale 



Etude de cas : Guichet automatique bancaire 


[ 

Le porteur de carte (soit client de la bonque soit client d’une autre banque) peut retirer 
de /'argent. 

Si le porteur est un client de la banque , li peut aussi consulter son compte, ou retirer un 
mini-releve bancaire. 

II peut aussi (client de la banque) modifier ses parametres de securite 

] 

Travail a faire : 

■ Identifier les acteurs et leurs cas d’utilisation associes 
Realiser le diagramme des cas d’utilisation 
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■A Les relations entre cas d’utilisation 

UML definit 3 principaux types de relations entre cas d'utilisation : 
■ L’ heritage 


Definition 


On dit qu'un use-case B herite d'un autre use-case A, quand A represente une 
generalisation de B 

Graphiquement, I'heritage entre cas d'utilisation est note de la meme maniere que celui 
des acteurs 



A IMPORTANT 

■ L'association d'heritage entre use-cases est utilisee principalement dans un souci 
d'organisation graphique du UCD 

■ En general, un use-case generique (dans I'exemple : « Gerer client ») n'a pas 
d’existence propre a lui, d'ailleurs il ne peut pas avoir de scenarios, il ne se realise 
qu'a trovers I'un de ses use-case derives 
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• L' inclusion 


Definition : « include » 


On dit qu'un use-case B est inclus d'un autre use-case A, quand le deroulement de B 
represente toujours une partie du deroulement de A 

Autrement dit, si B est inclus dans A, alors I'acteur ne peut realiser le use-case A, que si B 

est termine correctement. 

Graphiquement, la relation d'inclusion est notee par une fleche discontinue allant de A 
a B, accompagnee du stereotype « include » 



Exemple 

Etude de cas : GAB 


[... 

Pour pouvoir retirer de I’argent ou simplement consulter son solde, un client doit toujours 
s’authentifier en inseront so carte guichet, le systeme analyse la carte et demande le 
mot de passe ... 

...] 



o REMARQUES 

■ Si un use-case B est inclus dans un autre A, alors en general B n'est pas a 
proprement dit un vrai cas d’utilisation, car pour I ’ utilisateur du logiciel le cas 
d'utilisation B ne represente pas une fonctionnalite du systeme, done le fait 
d'associer I'acteur au use-case B serait une erreur. 

■ Une autre erreur courante est d'utiliser la relation « include » pour faire « le 
decoupage » d'un cas d'utilisation en plusieurs « sous cas d'utilisation » qui 
s'enchaTnent en fonction de certains criteres. 
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• L’ extension 


Definition : « extends » 


On dit qu'un use-case B etend un autre use-case A, quand B peut etre appele au cours 
de I'execution de A si une condition est verifiee (done pas toujours). 

Cette condition est appelee point d’extension. 

Graphiquement, la relation d’inclusion est notee par une fleche discontinue allant de B a 
A, accompagnee du stereotype « extends », cette fleche doit obligatoirement etre 
cormmentee par une note indiquant le point d'extension 



o 


REMARQUE 


On peut attacher une note a n'importe quel element graphique dans un diagramme 
UML 


Exemple 1 

Etude de cas : Gestion commerciale 


[... 

L’operateur de ventes peut enregistrer les commondes des clients , et choque 
commonde doit appartenir a un client parmi lo liste des clients enregistres dans le 
systeme. 

S’il s’agit d'un nouveau client Toperateur doit pouvoir le creer avant de lui enregistrer sa 
commande, ... 

...; 



Point d'extension: 
Nouveau client 


Exemple 2 

Etude de cas : Gestion electronique des actes de ventes immobilieres 


[... 

Le notaire doit pouvoir disposer d’une nouvelle fenetre pour la creation de chaque 
contra t. 

Chaque contrat contient une liste de vendeurs et une liste d’acquereurs, le notaire doit 
done pouvoir choisir un client parmi la liste des clients (si le client existe deja), et I’ajouter 
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soil dans la lisle des vendeurs, soil dans celle des acquereurs. 

S’il s’agit d’un nouveau client il doit d’abord le creer. 

Lors de la creation d’un client (si le client est marie) le notaire doit pouvoir specifier les 
informations relatives au conjoint du client. Si le conjoint du client n’existe pas , il doit 
d’abord le creer. 

■1 

Exigences fonctionnelles : 

■ Creer un contrat 

■ Ajouter un client dans liste des vendeurs 

■ Ajouter un client dans liste des acquereurs 

■ Creer un client 

■ Creer le conjoint d'un client 

Diagramme des cas d'utilisation : 




Pt d'extension: 
Nouveau client 
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Etudes de cas : 


Guichet automatique bancaire 


[ 

N’importe quel porteur de carte bancaire peut retirer de I’ argent, ou (s’il le souhaite) 
retirer de T argent avec un repu. 

Si le porteur est un client de la banque, il doit pouvoir acceder aussi aux services 
suivants (en plus du retrait d' argent) : 

Deposer de I’argent, retirer un mini-releve bancaire de son compte, consulter son solde, 
payer la facture d’abonnement du telephone fixe et modifier ses paramefres de 
securite. 

Un porteur de carte ne peut acceder a aucun service du GAB sans etre d’abord 
authentifie. 

] 

Travail a faire : 

■ Identifier les acteurs et leurs cas d’utilisation associes 
Realiser le diagramme des cas d’utilisation 


Gestion commerciale 


l 

Pour passer une commande le client s’ adresse au receptionniste, celui-ci passe la 
commande (commande normale ou express) si le client existe deja, sinon il doit d’abord 
le creer. 

Le comptable et le directeur des ventes peuvent enregistrer la facture de chaque 
commande dont le paiement est dOment regie. 

Le livreur doit enregistrer chaque livraison qu'il effectue. 

Pour les commandes dont la liste de produits n ’existe pas en quantite suffisante, le 
directeur des ventes peut aussi gerer le stock pour eviter toute rupture de produits. 

La gestion du stock contient les fonctionnalites suivantes : 

Gerer un produit, et enregistrer une demande d’ alimentation du stock 
La gestion d’un produit contient les fonctionnalites suivantes : 

Ajouter, supprimer et mettre a jour un produit 

Chaque utiiisateur du systeme, doit d’abord s’authentifier avant de pouvoir acceder a 
n’importe quelle fonctionnalite. 

1 

Travail a faire : 

■ Identifier les acteurs et leurs cas d’utilisation associes 
Realiser le diagramme des cas d’utilisation 
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Gestion de reservations d'hotel 


[ 

La direction d’un hotel souhaite creer un systeme informatique pour la gestion des 
chambres et des reservations. 

Ce systeme sera compose de deux parties, un site web pourles reservations des clients 
par internet, et une application Windows pourles employes de I’ hotel. 

Un visiteur normal du site peut uniquement afficher la liste des chambres. 

S’il s’agit d’un client, il peut modifier ses informations (login, password, nom, numero de 
telephone, ...), afficher la liste des chambres, passer une reservation ou bien annulersa 
reservation. 

Au cas ou c’estle receptionniste qui enregistre la reservation pourle client, il 
(receptionniste) doit d’abord ajouterle client si ce dernier n’est pas encore enregistre 
dans le systeme. 

De meme, si c’est un nouveau client qui passe la reservation, il doit d’abord creer un 
compte. 

Le receptionniste peut egalement afficher la liste des chambres disponibles, la liste des 
reservations, et la liste des clients. 

Le gerant quant a lui, peut en plus de cela, gerer la liste des clients. 

La gestion de la liste des clients comprend I’ajout, la mise a jour, et la suppression de 
clients. 

Chaque utilisateur du systeme doit s’authentifier, sauf les visiteurs normaux, pour 
I’affichage de la liste des chambres. 

] 

Travail a faire : 

■ Identifier les acteurs et leurs cas d’utilisation associes 
• _ Realiser le diagramme des cas d’utilisation 


Gestion de mediatheque 


I 

Le systeme d ’informations d’une mediatheque de livres informatiques comporte deux 
interfaces graphiques : un site internet pourles clients, et une application Windows pour 
les bibliothecaires et I’administrateur. 

Le site internet est ouvert a tout internaute pour p arcourir la liste des livres , afficher le 
sommaire d’un livre ou encore, creer un compte d'adherenf. 

Si I’internaute est un adherent, il peut aussi (apres s’etre authentifiel creer un panier , 
enreaistrer un panier pour une modification ulterieure, ouvrir un panier deia cree, v glider 
I’achat d’un panier (un panier contient au moins un livre). 

II peut aussi (/’adherent) modifier les informations de son compte (nom, prenom, ...) ou 
signaler au systeme au’il a oublie son mot de passe . 

Le bibliothecaire (utilisateur de / ’interface Windows) doit pouvoir aiouter ou supprimer un 
livre, aiouter ou supprimer une categorie de livres (developpement, base de donnees, 
systemes & reseaux, ...), ou encore afficher la liste des paniers valides , et la liste des 
paniers livres . 

Un livre ne doit pas exister dans la mediatheque, sans appartenir a une categorie. 

Done lors de I’ajout d’un livre, sa categorie doit etre specifiee. S’il s’agit d’une nouvelle 
categorie, elle doit etre d’abord creee. 

L’administrateur (lui aussi utilisateur de / ’interface Windows) doit pouvoir afficher fous les 
compfes ufilisafeurs (qu’ils soienf de fype adherent ou bibliothecaire), supprimer ou creer 
un compte bibliothecaire, ou modifier les informations de son propre compte a lui (nom, 
prenom, mot de pass e, ...). 
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II doit aussi (I'administrateur) pouvoir afficher la liste des paniers valides, et la liste des 
paniers livres, et afficher la recette du jour et la recette du mois. 

Bibliothecaires et administrateur doivent aussi s’ authentifier. 

] 

Travail a faire : 

■ Identifier les acteurs et leurs cas d’utilisation associes 

■ Realiser le diagramme des cas d'utilisation 
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